Summary

home_status_target matched its lock/door device group with a bare contains, so a word that merely contains "lock"/"door" as a substring misrouted to home_status — "is the clock on" (c[lock]) reported the door locks, and "out[door]" collided the same way. Match the tokens as whole words, mirroring the existing ice/iron/cooktop/cover fixes. Closes #831.

Changes

• In home_status_target, replace the substring contains_any(&target, &["lock", "locks", "door lock", "door locks", "door"]) with a whole-word target.split_whitespace().any(|word| matches!(word, "lock" | "locks" | "door" | "doors")). The multi-word "door lock"/"door locks" entries are redundant once the words match and are dropped; "doors" is added so "are the doors locked" keeps resolving.
• New test lock_and_door_status_match_whole_words_not_substrings: three substring cases (clock/block) must not resolve to "locks"; four genuine lock/door queries (bare → "locks", named → full entity) must still resolve.

Real Behavior Proof

• I have built and run the affected code locally (or noted why I could not).
• I have verified the change end-to-end on Jetson hardware.
• I have NOT verified on Jetson hardware, and I explain the equivalent verification path or validation gap below.

Tested profile / hardware (check all that apply):

• jetson
• raspberry_pi
• portable_sbc
• laptop
• mac
• CI-only / docs-only
• Not run locally

What I ran

x86_64 Linux dev machine (laptop profile), rustc 1.98.0-nightly, branch cut from 7c67906. The changed path is pure string routing in quick::route — no audio/HA/hardware dependency — so route() unit tests exercise it end-to-end; the validation gap is only that I did not run the voice loop on a device.

1. Wrote the failing test first and ran it against unmodified main: cargo test -p genie-core --lib lock_and_door_status
2. Applied the fix and re-ran, then the full gates:
   • cargo fmt --all -- --check
   • cargo clippy -p genie-core --all-targets --locked -- -D warnings
   • cargo test -p genie-core --lib and cargo test -p genie-core --lib --no-default-features

What I observed

Before the fix (new test against unmodified main):

"is the clock on" must not resolve to the locks status entity
test result: FAILED. 0 passed; 1 failed

i.e. route("is the clock on") → home_status{entity:"locks"}.

After the fix:

• route("is the clock on") → abstains
• route("is the wall clock right") → abstains
• route("is the block heater on") → abstains
• unchanged: "are the doors locked" / "is the door locked" → home_status{entity:"locks"}; "is the side door locked" → "side door"; "is the garage door closed" → "garage door"

Gate results: fmt clean; clippy clean under -D warnings; lib tests 938 passed / 0 failed (default) and 840 passed / 0 failed (--no-default-features). The existing door/lock status tests ("Is the garage door closed?" → "garage door", "Is the side door locked?" → "side door", "What doors are unlocked?" → "unlocked doors") continue to pass.

Test plan

• cargo test -p genie-core --lib lock_and_door_status — the new case fails on main, passes here.
• cargo test -p genie-core --lib status — the home_status suite (including the existing whole-word sibling tests) stays green.

Notes for reviewers

This is the same substring→whole-word conversion applied to the neighbouring groups in #792 (ice/iron/cooktop) and #802 (cover/gate); the lock/door group was the remaining substring matcher in home_status_target. "outdoor" no longer trips the door arm, and "clock"/"block" no longer trip the lock arm, while "doors" was added to the token set so the bare-plural "are the doors locked" still collapses to "locks".

Summary by CodeRabbit

• Bug Fixes
  • Improved lock and door query detection by matching whole words instead of substring text, preventing false matches from unrelated phrases containing “door” or “lock” as part of other words.
  • Added test coverage to verify abstention for common false-positive examples while preserving correct routing for genuine queries like “doors locked,” “side door locked,” and “garage door closed.”